Blog

Brad Wood

December 17, 2017

Spread the word


Share your thoughts

In this installment of The 12 Tips of (CommandBox) Christmas we'll talk about a CommandBox module called CFConfig that will make your life a whole lot easier.  A couple of days ago we covered the server.json file which helps you define what CF engine to use (Lucee, Adobe, etc) and your JVM settings and web server settings in a way that is easy to distribute to you coworkers.  There was one big thing missing though and that is all of the settings that you put in your ColdFusion administrator like datasources, CF mappings, and request timeouts.  Well, Christmas has come early this year because CFConfig is the piece of the puzzle that does that for you!

All the settingz

 CFConfig gives you the ability to manage most every setting that shows up in the web administrator, but instead of logging into a web interface, you can manage it from the command line by hand or as part of a scripted server setup.  You can seamlessly manage config for all the following:

  • CF Mappings
  • Datasources
  • Mail servers
  • Request, session, or application timeouts
  • Licensing information (for Adobe)
  • Passwords
  • Template caching settings
  • Basically any settings in the web based administrator

Do I have to use CommandBox servers?

Nope!  CFConfig will work on any CF server regardless of how it was installed.  Since it interacts directly with the config files, the server doesn't need to be running.  Heck, the server doesn't even need to be installed yet!  CFConfig can be used to write out config files before you even start a CommandBox server for the first time.  

But it's not just for CommandBox servers.  All you need is the folder path to the CF home in your server installation and you can point the CFConfig library at it.  This means CFConfig can be used for syncing config across existing servers, standing up docker containers, or provisioning Vagrant VMs.

Show me the XML

CFConfig interfaces directly with the XML and property files used by your CF engine to store its configuration.  It takes care of translating the config properly so you use the same commands regardless of what engine you're managing the config for. The tool will try hard to figure out the version of ColdFusion or Lucee that you have installed and there are hints you can give it as well.  Both ACF and Lucee also have settings to monitor the config files for changes so you don't even need to restart the server to pick up your changes.

Let's try it

To use CFConfig, you can install it into CommandBox easily like so.  Remember, new versions are coming out on a regular basis right now, so don't forget to update it often (you can just re-run the install command)  These commands will work on any CF engine and if you run them from the root of CommandBox server they will "just work" as it will "find" the server for you.  To run these commands against another type of server, you'd need to specify a folder path for the "from" or "to" parameters that pointed to the server home directories.  

CommandBox> install commandbox-cfconfig

Now that you've got the tool installed you can dig into the command help to see where to go from there.  Here's a quick overview of some of the commands.  Run the built-in command help for more info on each one.

View a setting

CommandBox> cfconfig show requestTimeout

Set a setting

CommandBox> cfconfig set requestTimeout=0,0,10,0

View all settings for a server

CommandBox> cfconfig show

Add, list, and delete a CF Mapping

CommandBox> cfconfig cfmapping save virtual=/foo physical=C:/bar
CommandBox> cfconfig cfmapping list
CommandBox> cfconfig cfmapping delete /foo

Add, list and delete a datasource

CommandBox> cfconfig datasource save name=myDSN dbdriver=mysql host=localhost port=3306 database=myDB username=brad password=foobar
CommandBox> cfconfig datasource list
CommandBox> cfconfig datasource delete myDSN

Export all settings from a server

CommandBox> cfconfig export .CFConfig.json

Import settings into a server

CommandBox> cfconfig import .CFConfig.json

Transfer settings from one server to another

CommandBox> cfconfig transfer from=oneServer to=anotherServer

Diff all the settings between two servers

CommandBox> cfconfig diff to=anotherServerName
CommandBox> cfconfig diff to=anotherServerName --fromOnly
CommandBox> cfconfig diff to=anotherServerName --toOnly
CommandBox> cfconfig diff to=anotherServerName --valuesDiffer

This is just the beginning.  To read the docs on CFConfig and find out more about some of the special CommandBox interceptors that will automatically load in config when you start up a server, click here:

https://cfconfig.ortusbooks.com/using-the-cli/server-interceptors/server-start.html

Add Your Comment

(3)

Dec 17, 2017 20:04:28 UTC

by sean hogge

So I get that these are sort of high-level exposures meant to whet an appetite to dive deeper, but one thing that I think might be handy is to outline what differences exist between CFConfig, Application.cfc, and server.json. You can set custom tag paths and datasources in app.cfc. You can set up engines in server.json. Why would someone use CFConfig over either or both of those other options?

Dec 17, 2017 22:07:10 UTC

by Brad Wood

Hi Sean, great questions. That probably warrants a separate post in the future. server.json doesn't really doesn't overlap Application.cfc or CFConfig at all but CFConfig does overlap Application.cfc a bit. The main reasons you'd use CFConfig is:

1) Application.cfc only covers a pretty small amount of the total configuration options in the web administrator
2) If you're on an older engine, or Adobe in general, Application.cfc is very VERY limited
3) CFConfig gives you tools like the diff function and import/export to move different settings between servers
4) Certain settings actually can't be in Application.cfc at all if they are compile settings like full null support in Lucee.
5) Lucee and Adobe don't have consistent support for things like datasources. An example is datasources-- they use different JDBC class names which CFConfig handles for you.

So in short, feel free to use your Application.cfc for what it can handle, but for everything else there's CFConfig which is far more comprehensive. With the CLI tooling and external JSON storage, CFConfig helps you externalize your config a bit more and even automate the management of it in a way that Application.cfc just doesn't allow.

Dec 21, 2017 17:37:32 UTC

by sean hogge

I'd definitely like to see a dedicated post to this topic at some point. I don't see why you can't diff outside CfConfig just as easily (are we talking windows, here?), and some examples of how to accomplish common tasks done different ways would be very interesting to me. Thanks for the quick run-down!

Recent Entries

Partner with BoxLang and Ortus at Into the Box 2025: Empowering the Future of Modern Software Development!

Partner with BoxLang and Ortus at Into the Box 2025: Empowering the Future of Modern Software Development!

At Ortus Solutions, we’ve always been at the forefront of innovation in the ColdFusion ecosystem. From pioneering modern ColdFusion practices to developing cutting-edge tools and frameworks, we’ve been passionate to help and sup[port the community into shaping the future of web development.That’s why we decided to build BoxLang, our new JVM programming language that not only builds on the strengths of ColdFusion but takes modern software development to the next level.

Maria Jose Herrera
Maria Jose Herrera
December 23, 2024
Why BoxLang When You Have Kotlin, Groovy, Scala, and more…

Why BoxLang When You Have Kotlin, Groovy, Scala, and more…

As we approach a stable release of BoxLang and our continued marketing reaches more folks, many have asked about its purpose. Why create a new language when the JVM ecosystem already includes established languages like Kotlin, Groovy, and Scala, to name a few.

Luis Majano
Luis Majano
December 18, 2024